Scripts written using various scripting languages, such as TypeScript, JavaScript, AJAX (Asynchronous JavaScript and XML), etc., have generally been restricted to run in a browser sandbox for security purposes. However, the usage of HTML “iframes” (inline frames) allows a page from one domain to contain content from another page on another domain. However, for security purposes, code in one iframe from one domain is not allowed to directly call code in another iframe from another domain.
Attempts to create some form of interoperability between iframes has led to the creation of a simple mechanism, conventionally referred to as the “postMessage” method, to communicate text strings across iframes from different domains. No executable code is allowed to be passed over the postMessage channel between iframes, just text strings.
In particular, the well-known postMessage method allows cooperative text exchange between non-trusted modules from different domains embedded within a page. It does so by ensuring a consistent and secure process for text-based data exchange. Using this method, when a script (e.g., TypeScript, JavaScript, AJAX, etc.) invokes the postMessage method on a window object, the browser sends an “onmessage” event to the target document on which the data property has been set to the value passed in the postMessage message. Further, for security, when a target Unique Resource Identifier (URI) (specifying a protocol and a host) is passed a message using the postMessage method, the message will only be received by the target window if it has the same protocol and host as the source URI.
Further, because the well-known postMessage method used with iframe coding allows only simple text strings to be passed from one iframe to another, conventional communication across iframes using the postMessage method is subject to various limitations. For example, the postMessage method is unstructured, such that no notion of object identity nor separate fields within that object, are provided. Note that using conventional techniques, simple serialization can provide some structure of fields, but doesn't allow for object identity. In addition, the postMessage method is dynamically typed, rather than statically typed, with the result that opportunities to prevent entire classes of errors are lost because such errors will only be exposed at runtime. Further, the postMessage method is one-way, such that richer patterns of control flow, such as, for example, asynchronous methods, events, lazy evaluation, and progress callbacks, are not available via conventional postMessage-based techniques.